home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus Special 23 / AMIGAplus Sonderheft 23 (2000)(Falke)(DE)[!].iso / Updates / Librarys / MMULib / Autodocs / exceptions.doc < prev    next >
Text File  |  1999-05-26  |  36KB  |  808 lines
  1.         E X C E P T I O N - H A N D L E R   D E T A I L S
  2. ------------------------------------------------------------------------------
  3. Abstract:
  4.     This document defines the exception handler mechanism of the mmu.library
  5.     and how to make use of it.
  6.     Please study it carefully before you try to implement an mmu.lib
  7.     exception handler. 
  8.  
  9.     For details about the concepts of a "context", read the mmu.doc.
  10. ------------------------------------------------------------------------------
  11. What is a bus error exception:
  12.  
  13.     A bus error can be understood as a sort-of "interrupt" which is triggered
  14. by either a software fault or a hardware signal related to acessing memory
  15. or external devices in an unsupported fashion, like accessing a non-available
  16. memory location or writing to a write-protected memory region.
  17.  
  18. All bus errors are re-directed to the MMU.library, but some of them remain
  19. unhandled and are passed over to the exec.library. Some of the remaining
  20. errors are handled automatically by the library, and those that remain
  21. will cause your "context hooks" to be called, as installed by the
  22. "AddContextHook" and "AddMessageHook" vectors of the mmu.library.
  23.  
  24.  
  25. The members of the MC680x0 family generate so called "bus error" for the
  26. following situations:
  27.  
  28. - True physical bus errors: 
  29.  
  30.     The CPU tried to access an external device, but this request was aborted
  31.     by pulling the "bus error input" control line (TEA) of the CPU low. 
  32.     These bus errors are generated by an external bus control logic, avail-
  33.     able for some Amiga models, on access of non-available memory.
  34.  
  35. - Access errors:
  36.  
  37.     These errors are generated by the MMU for a non-valid access of
  38.     a memory "page". As far as the MMU is concerned, complete memory is
  39.     split into adjacent pages of a fixed size, usually of size 1K or 4K,
  40.     and the MMU holds access rules, the so called "properties" for each
  41.     of these pages. If these rules are violated, an access error is
  42.     generated. The following violations may arise:
  43.  
  44.     The CPU tried to access a page of memory marked by the MMU as 
  45.     "non-resident", or tried to write to a memory block which is write-
  46.     protected, or tried to access a memory block in user mode which is
  47.     marked as "supervisor only" access.
  48.  
  49. Of all of these bus errors, the mmu.library handles only the part which it
  50. is "interested in". True physical bus errors are not handled by the 
  51. MMU.library and passed thru to the exec exception handler - which again, calls
  52. the exception handler of the task that caused the exception. Additionally,
  53. the MMU.library does not try to fix bus errors caused by so called "locked
  54. transfers", i.e. the instructions "TAS","CAS" and "CAS2". These instructions
  55. are only useful for multi-processor machines and not supported by the Amiga
  56. hardware architecture anyways. A legal Amiga program *must not* use them.
  57.  
  58. Furthermore, the "MOVE16" instruction accesses of the 040 and 060 processors
  59. are not handled, too, for the same reason. All these errors are passed thru
  60. to exec, and remain unhandled. They will usually force a fatal software 
  61. failure.
  62.  
  63. An additional special case - which might be interesting for the experts -
  64. is writing to memory by "instruction function code". This is only possibly
  65. by loading this function code to the "dfc" register and then using the
  66. privileged "moves" instruction to write instruction data. This is unsupported,
  67. too. Just write instructions with "move", then flush the cache. This is, too,
  68. what the dos.library does when loading code.
  69.  
  70.  
  71. All remaining accesses are handled by the MMU library, and are first filtered
  72. again. The MMU library distinguishes:
  73.  
  74. -    User mode and supervisor mode accesses.
  75.  
  76. All exec tasks MUST run in user mode, and this is the "default" situation.
  77. The user mode exceptions are handled according to the "MMU context" they
  78. are generated by, or, equivalently, the context the current task is attached
  79. to. All supervisor mode accesses are managed by one single context, the 
  80. "supervisor context".
  81.  
  82. -    Data vs. instruction accesses.
  83.  
  84. Whether the bus error happened due to faulted access of data, or whether 
  85. the CPU tried to fetch instructions, and this instruction fetch faulted.
  86. Instruction write accesses, as they might have been generated by a "moves",
  87. might or might not be handled, this is implementation specific. The CPU
  88. itself never generates these accesses when fetching code, the only 
  89. possibility is a "moves" instruction.
  90.  
  91. -    Read vs. write accesses.
  92.  
  93. Whether data was about to be read by the CPU, or the CPU tried to write
  94. out data. Instruction accesses by the CPU are always of reads.
  95. Accesses to the stack, as for subroutine calls or "link" instructions
  96. are regarded as data accesses, too. (Read about special caveats about
  97. the stack, below!)
  98.  
  99. Amongst all these types, the MMU library handles certain special cases
  100. automatically. You never see these faults from your context hooks, they
  101. are completely transparent and handled by the library as a special service.
  102.  
  103. -     AbsExecBase reads.
  104.  
  105. To be able to mark the first memory page as "invalid", the MMU library
  106. filters out accesses to AbsExecBase itself in the first stage of the exception
  107. handler, to emulate them as fast as possible. The library will try to emulate
  108. the most popular instructions in software, for optimal performance. However,
  109. still try to avoid reading AbsExecBase in your code. Make a copy to a static
  110. library base on startup, and then use this backup copy whenever possible.
  111. Most modern C compilers do that automatically anyways, but assembly language
  112. authors should keep this in mind.
  113.  
  114.     DON'T (slow!)                            DO (fast)
  115.  
  116.     move.l AbsExecBase,a6                    move.l mn_SysBase(a4),a6
  117.  
  118.  
  119. In case the special threatment of AbsExecBase is not desired, set the 
  120. MCXTAG_EXECBASE tag value of the CreateMMUContext() call to FALSE. This might
  121. be interesting for emulators, for example.
  122.  
  123. Remember that interrupt code is handled by the supervisor context, AND NOT
  124. BY YOUR USER CONTEXT. Hence, accessing AbsExecBase from within interrupts is
  125. always valid, simply because the supervisor context is always build by the
  126. library itself, and this flag is always set on creation of this context. 
  127. DO NOT touch the supervisor context unless you know precisely what you're
  128. doing.
  129.  
  130.  
  131. -    Accesses above 0x0400 in the first memory page.
  132.  
  133. The mmu.library emulates accesses above addresses 0x0400 to the first
  134. page in memory. This is again to allow setting the first page to "invalid"
  135. for tracing access errors in the autovector region. Accesses to addresses
  136. above and including 0x400 in the first page are therefore always legal.
  137. This feature can be disabled again with the MCXTAG_EXECBASE flag, see above.
  138.  
  139. AVOID THESE ACCESSES, THEY ARE EMULATED IN SOFTWARE AND VERY SLOW.
  140.  
  141. Starting with Os 3.0, exec tries to help these MMU programs by starting 
  142. chip memory at 0x1000, not at 0x0400 as usual, if a 040 or 060 CPU is
  143. available. This means that for page sizes of 4K for the 040 and 060, and
  144. for page sizes of 1K for the 030 and 68851/020 MMU, no accesses need to
  145. be emulated. Please keep this in mind when using the MMU because THE 
  146. EMULATION CODE IS SLOW. Try to use these "natural" page sizes whenever 
  147. possible.
  148.  
  149. If not possible, try to relolate the libraries and buffers in this memory
  150. region, usually some graphics.library buffers, the expansion library base,
  151. and - possibly - the exec library.
  152.  
  153. Trying to execute code in this memory region does work, but is really, really
  154. slow. Each instruction access has to go thru the mmu.library exception
  155. handler, so feel prepared that your computer runs in "slo-mo mode" if you
  156. don't follow these rules.
  157.  
  158.  
  159. - Writes to MAPP_ROM pages.
  160.  
  161. The mmu.library tries to cancel writes to pages marked as "ROM". Writes
  162. to these pages will generate an access error, which is "ignored" by
  163. the mmu.library. Hence, memory regions marked as "ROM" will get an
  164. effective "silent" write protection. However, keep in mind that a write
  165. to "ROM" area is still slow because it includes running the exception handler.
  166. This goes even more for the 060 CPU because it includes copying the "ROM"
  167. to a dummy writable backup page into which the write is then redirected.
  168.  
  169. Special care must be taken for "misaligned" writes, i.e. writes that hit
  170. the "border" of a ROM region and go par